In LTE systems and LTE-A systems, the system information is defined by one or more system information blocks (SIB) and a master information block (MIB). The system information may comprise one or both of non-access stratum and access stratum related information. For the purpose of the present application, a MIB is considered as a particular kind of a SIB if not otherwise stated or made clear from the context.
In LTE systems and LTE-A systems, the MIB and one SIB (SystemInformationBlockType1, also named SIB1) are regularly broadcasted on the BCH at predetermined points of time. SystemInformationBlockType1 informs the UE on the time when the other SIBs are broadcasted.
In LTE systems and LTE-A systems, a concept of a BCCH modification period is used for changes (updates) of the system information (SI), i.e. a change of SI (other than for ETWS, CMAS and EAB parameters) only occurs at specific radio frames. The BCCH modification period boundaries are defined by SFN values for which SFN mod m=0, where m is the number of radio frames comprising the BCCH modification period [1].
The concept is shown in FIG. 1, which shows broadcast SIBs over time. Broadcast system information (SI) is comprised of several system information blocks (SIBs) indicated as squares in FIG. 1. In the simple illustration in FIG. 1 hashed squares indicate different SIB from the non-hashed squares. In BCCH modification period (n), the UE is notified on the change of SI, in the example of FIG. 1 about the change of SIB of hashed square. The change of the SI becomes effective at the boundary to the next BCCH modification period (n+1): Diagonal hashing changed to horizontal hashing indicating the change of that particular SIB.
There are two ways for SI change notification:                A paging message is used to inform UEs in RRC_IDLE and UEs in RRC_CONNECTED about a system information change. If the UE receives a paging message including the systemInfoModification message, it knows that the system information will change at the next BCCH modification period boundary.        SystemInformationBlockType1 includes a value tag, systemInfoValueTag, that indicates if a change has occurred in the SI messages, i.e. if any change occurred in SI. E.g. upon return from out of coverage, an UE may use systemInfoValueTag to verify if the previously stored SI messages are still valid.        
The UE verifies that stored system information remains valid by either checking systemInfoValueTag in SystemInformationBlockType1 after the BCCH modification period boundary, or attempting to find the systemInfoModification indication at least modificationPeriodCoeff times during the BCCH modification period in case no paging is received, in every BCCH modification period. According to 3GPP TS 36.331, the BCCH modification period may be calculated as follows:BCCH modification period=modificationPeriodCoeff*defaultPagingCycle,wherein the BBCH modification period and the default paging cycle are expressed in number of radio frames.
In general, there are one or more paging occasions during each BCCH modification period.
In RAN #67, a work item for release 13 RAN enhancements for extended DRX in LTE was agreed [2], with the objectives to extend DRX for UEs in IDLE (RRC_IDLE) mode (also named “I-eDRX”) and CONNECTED (RRC-CONNECTED) mode for UE power saving. The length of extended DRX is 5.12 or 10.24 seconds for RRC_CONNECTED, but can be beyond 10.24 seconds for RRC_IDLE. Maximum value of the eDRX for RRC_IDLE is 43.69 minutes which is 256 times 10.24 s.
When the extended DRX length is much larger than the BCCH modification period, the UE might miss paging for SI modification notification, and there is a potential risk of the valueTag (systemInfoValueTag) in SIB1 wrapping around during eDRX. Namely, the valueTag is a numerical value which is updated at every change of SI, e.g. by incrementing 1. If the maximum value of the valueTag is reached, it is reset to 0, and then incremented again. Thus, after a maximum number of SI changes, the valueTAG has the same value again (wrapped around). The valueTag is presented with 5 bits allowing values between 0 and 31.
Options for the SI update that have been proposed are the following:    1) UE checks the systemInfoValueTag in SIB1 just before it has to become reachable within I-eDRX cycle; details explained below:            Case a) If the I-eDRX is shorter than the BCCH modification period, the UE behaves as legacy, i.e. it follows SI change notification for common SIBs through paging.        Case b) If the I-eDRX is longer than the BCCH modification period, the UE checks the systemInfoValueTag in SIB1 just before becoming reachable in its paging occasion (referring to the time window when this UE may be paged in its specific PO/PF). This case implies that the UE can ignore the systemInfoModification notifications conveyed in paging message while in I-eDRX.            2) UE checks the systemInfoValueTag in SIB1 once per I-eDRX cycle. This option implies that the UE can ignore the systemInfoModification notifications conveyed in paging message while in I-eDRX.    3) UE behaves as legacy i.e. it follows SI change notification for common SIBs through paging.    4) UE reads the system information always when the eDRX is longer than the 32*BCCH modification period which is the minimum time for wrap-around of the SI value tag (5 bit information in SIB1). Otherwise the UE relies on the value tag indication.
In general, it is an intention to minimize the cases when the UE has to read system information while it is still being kept updated with the SI modifications.
A problem with the 1st option is the un-optimized UE behaviour as the UE has to read at least SIB1 each time the length of eDRX is longer than the BCCH modification period.
The 2nd option forces UE to read the SIB1 always when waking up from eDRX. That will not be desirable as the eDRX is meant to minimize UE activity and thus the power consumption.
The option 3 has the problem that the UE will miss the SI change notifications sent with one or more paging messages during the sleep time of the eDRX cycle. When waking up, the UE will not be aware nor given an indication about the changes of SI except the value tag (which has its own problems, i.e., may be wrapped around).
The 4th option is a feasible solution but the time triggering the SIB reading can be unnecessarily short when the configured BCCH modification period is short and the eDRX period exceeds that period. Hence, the option does not result in minimum possible power consumption.
In practical implementations and network operation, the system information does not change very frequently, so reading all SIBs just in case there was a wrap-around consumes a lot of power. Avoiding reading the SIBs when they have not changed would be beneficial.